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not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 
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Abstract 


Working Party 1/2, of the International Telecommunication Union 
Telecommunication Standardization Sector (ITU-T) held a meeting of 
its collaborators in Berlin Germany 19-26 October 2000. The agenda 
of the meeting contained several contributions regarding RFC 2916: 
"E.164 Number and DNS" from the Internet Engineering Task Force's 
(IETF) ENUM Working Group - more specifically, the method for 
administering and maintaining the E.164-based resources in the Domain 
Name System (DNS) as related to the ENUM protocol. Consequently, in 
addition to the WP1/2 collaborators, there were several members of 
the IETF present to assist with the discussion of issues contained in 
the aforementioned contributions. 


This liaison from WP1/2 to the IETF/ISOC conveys the understandings 
of the WP1/2 collaborators resulting from the discussions. 


1. Considerations under Question 1/2 (Numbering) 


Throughout this document, the terms "administration" or 
"administrative functions" refer to the provision and update of the 
E.164 numerical values, to be contained in the zones of a domain name 
in the "el64.arpa" domain, in the DNS. 


It is noted that most ENUM service and administrative decisions are 
national issues under the purview of ITU Member States, since most of 
the E.164 resources are utilized nationally. 


These understandings are relative only to the provision of E.164 
information for DNS administrative functions, not policy or 
operational functions. 
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In order to advance a common terminology for the purpose of this 
liaison, we have defined the zones of a domain name as follows. 


Using an example, domain name "1.5.1.5.0.2.0.4.1.3.3.e164.arpa" 
in RFC 2916) is segmented into zones as follow: 


E164.arpa - domain zone 
3.3. - country code zone (1, 2, or 3 digits dependent on CC) 
1.5.1.5.0.2.0.4.1. - national zone 


The first understandings to be conveyed are those regarding the 
responsibilities for administration of the various zones within 
"el64.arpa" domain: 


o The domain zone administration was agreed to be outside the s 
of this meeting and WP1/2. 


o For all E.164 Country Code Zone resources (Country Codes and 
Identification Codes), the ITU has the responsibility to prov 
assignment information to DNS administrators, for performing 
administrative function. The ITU will ensure that each Membe 
State has authorized the inclusion of their Country Code 
information for input to the DNS. For resources that are spa 
designated as test codes there will normally be no entry in t 
DNS. However, the ITU will provide spare code lists to DNS 
administrators for purposes of clarification. The entity to 
E.164 test codes have been assigned will be responsible for 
providing any appropriate assignment information to DNS 
administrators. 


o The administration of National Zone numbering information is 
determined by the type of Country Code resource that a Nation 
Zone is behind: 


* The national zone, for geographic resources, is a national 
matter and is, therefore, administered by the ITU Member 
State(s) to which the country code is assigned. In an 
integrated numbering plan, e.g., CC "1", each Country with 
the plan may administer their portion of the resource in a 
different manner. 


* For national zone resources behind the Country Codes assig 
to and shared by Networks, the entity to which the resourc 
assigned provides the E.164 assignment information, to DNS 
administrators for performing the administrative function. 
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* For national zone resources behind the Country Codes assigned 
to and shared by Groups of Countries, the administrative entity 
identified by the Countries of the Group provides the E.164 
assignment information, to DNS administrators, for performing 
the administrative function. Note that the creation of this 
category is dependent upon the approval of draft Recommendation 
B.164.3. 


Each of the administrative entities responsible for the 
administration of resources within the zones (as identified above) 
is individually and separately responsible for ensuring that DNS 
administrators are aware of appropriate changes to their resources 
once they have agreed to their input into the DNS. 


Assigned geographic E.164 resources, for all zones, not authorized 
for input by the appropriate administrative entity will not be 
entered into the DNS under any circumstance. For example, if the 
ENUM service is not approved for use in a country, by the 
appropriate ITU Member States, the E.164 numbers of that country 
will not be input to the DNS. 


With regard to Number Portability, it was agreed that WP1/2 would 
further study this issue, in the context of ENUM. However, it is 
currently understood that this study and its result will not 
impact the IETF and its work. 


The study being undertaken within WP1/2 (referred to above) will 
also attempt to identify options and provide guidance to assist 
those entities charged with the task of providing the 
administrative information to DNS administrators. 


All administrative entities, including DNS administrators, will 
adhere to all the applicable tenets of all pertinent ITU 
Recommendations, e.g., E.164, E.164.1, E.190, and E.195, with 
regard to the inclusion of the E.164 resource information in the 
DNS. 


The ITU, IETF, and IAB will jointly cooperate fully to ensure that 
the agreed administrative procedures to accommodate the above 
understandings, and any other mutually agreed appropriate future 
understandings, will be implemented and adhered to on an ongoing 
basis. The ITU may request the consultation of the WP1/2 experts 
as necessary and as prescribed in Resolution 20. 
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2. Additional items below are from Q.10/2 Rapporteur Group (Service 
Issues) 


o The issues surrounding number portability are to be addressed in 
the draft supplement to Recommendation E.370 


o This issue surrounding freephone service was expanded to include 
other global services (i.e., International Premium Rate Service 
and International Shared Cost Service). Preliminary findings 
would indicate that routing the call to the appropriate 
destination will depend on successfully receiving information 
about the geographic point of origination (e.g., calling 
"telephone Number"). A proxy server would process such 
information and either redirect or forward the call (based on the 
proxy owner’s decision) on to the appropriate destination. 


o The issue surrounding selection of the IP gateway within a PSTN- 
to-IP call flow may depend on options that may be available to 
telephony carriers in such selection. 


The WP1/2 collaborators thank their IETF counterparts who attended 
this meeting and assisted in the resolution of these issues. 


Any questions regarding the contents of this liaison should be 
referred to the WP1/2 Chairman Roy Blane at Roy_Blane@inmarsat.com. 


3. Security Considerations (added by the IESG) 


The ENUM solution uses the Domain Name System (DNS) for storage of 
information. Delegation and distributed administration is done 
according to DNS routines. The E.164 numbers are though distributed 
according to a different algorithm than domain names. 


This Liaison Statement describes how mapping E.164 number 
administration and DNS administration can work together, and how 
further discussions are delegated to each administrative body for the 
country codes in E.164 space. 


If delegation and mapping is not done carefully between E.164 and DNS 
there is a risk of "napping" of E.164 numbers when they are stored in 
DNS. It is also important that the DNS strictly hierarchal system is 
preserved (see RFC 2826 [1]). 


4. References 


[1] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, 
May 2000. 
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6. Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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